Как реагировать?

Есть 3 варианта реакции на выявленные проблемы:

— Коммуникация с другими подразделениями и внешними контрагентами

— Исправление процесса с владельцем процесса

— Управленческое воздействие на сотрудников

Большая часть бизнес-процессов на предприятии не изолирована, а связана с работой других подразделений. Даже, например, вход в ваш процесс обеспечивает какой-то другой. Если итоговые результаты вашей работы неудовлетворительны из-за ошибок, в поступивших к вам на начальном этапе входных данных — это повод обсудить ситуацию с руководителем другого подразделения. Поиск компромисса необходим для предотвращения дисбаланса, когда сверхэффективность одних подразделений может оборачиваться худшей результативностью других. Также ваш процесс может зависеть от работы подрядчиков, что не может снимает с вас ответственности как с менеджера процесса.

Результат вашего процесса зависит не только от внешних коммуникаций. Если результат не соответствует ожиданиям, возможно, сам процесс спроектирован неверным образом. Потребители могут жаловаться на качество, скорость или стоимость процесса. Вам как менеджеру, нужно понять, какие рекомендации владельцу процесса дадут наилучший результат. Например, входящий в разработку поток заявок от бизнеса принято классифицировать на: Инциденты. Новый функционал и другие категории. Это необходимо, чтобы наилучшим способом (баланс качества, скорости и стоимости) решить каждую из заявок. Каждый этап процесса уникален и требует переосмысления, ведь он может иметь отклонения от общих правил, адаптируясь под разные ситуации. Причины неудовлетворительного результата — описание процесса может быть либо недостаточно детализированным, либо наоборот слишком конкретным, что не дает сотрудником подходить к решению задач творчески.

Наконец, ваши сотрудники могут не соблюдать предписанный процесс (умышленно или неосознанно). Сами управленческие воздействия мы разбирали выше в блоке «Мотивации членов команды».

Одной из классических функций менеджера является Планирование. Для оптимизации собственных ресурсов остальным подразделениям важно понимать, когда вы сделаете ту или иную задачу.

Прогноз результатов строится из выходных результатов процесса, понимания доступных ресурсов на прогнозируемый период и из потенциальных изменений или рисков.

Проблема с метриками заключается в том, что сотрудники в погоне за видимостью результата могут предоставить вам лишь красивые цифры. Так часто происходит, когда бонусы привязываются к KPI. Не попадайте в эту ловушку, лучше, чтобы сотрудники не знали о том, какие вы хотите увидеть цифры и по каким метрикам.

Аналитика

Вход процесса: Заинтересованные лица, требования к системам

Цели процесса:

— Оценка объема аналитики по задачам

— Скорректированные ожидания заказчиков

— Согласованное описание требований заказчиков

— Обновленная документация продукта

— Обученные сотрудники, проведенное демо и др.

Метрики:

— Удовлетворенность работой аналитика (Заказчик/Архитектор/Разработчик/…)

— Количество задач с описанными требованиями

Программирование

Вход процесса: Согласованные требования по задаче

Цели процесса:

— Оценка сложности и времени выполнения задач

— Написание кода, реализующего рабочие требования

— Проверка соответствия кода соглашениям/стандартам

Метрики:

— Соответствие времени решения задачи плановым показателям

— % прохождения статического анализа кода

— % прохождения автоматизированного тестирования

— % прохождения ручного тестирования

— Количество выполненных задач

— Объем выполненных задач

Контроль качества

Вход процесса: Выполненная задача

Цели процесса:

— Оценка сложности и времени тестирования задач

— Соответствие нового функционала заданным требованиям и ожиданиям заказчика

— Отсутствие дефектов в связи с внедрением нового функционала

Метрики:

— Оценка сложности и времени тестирования задач

— Среднее время ожидания тестирования

— Скорость тестирования задач

— % пропущенных ошибок

— % автоматизированных тест-кейсов

Качество можно рассматривать шире, например в рамках теории Total Quality Management.

Публикация новых версий

Вход процесса: Готовая к публикации новая версия

Цели процесса:

— Опубликованная новая версия

— Минимальный ущерб в связи с публикацией новой версии (простой, ошибки)

— Минимальная стоимость процесса сборки и публикации

Метрики:

— Среднее время ожидания публикации задачи после успешного тестирования

— Сумма простоя в процессе публикации

— Количество инцидентов во время публикации

— Количество публикаций в целом

Обслуживание и поддержка

Вход процесса: Система, с которой работают пользователи

Цели процесса:

— Минимизация времени обслуживания заявок пользователей

— Минимизация отказов и времени даунтайма системы

— Минимизация стоимости процесса

Метрики:

— Метрики SLA

— Uptime

— Количество специалистов, необходимых для поддержки функционирования систем

Используйте post-mortem отчеты для анализа инцидентов доступности продукта. Они помогут команде исправить причины, которые привели к инциденту или деградации.

Прием, распределение и контроль задач в подразделении

Качество постановки задач

Какие задачи у вашей команды, кто их и как ставит? Ощущение вас как руководителя складывается в первую очередь из поставленных задач и того, как вы их принимаете. Все это делают по-разному. Одним достаточно контролировать техническую часть, поручая контроль закрытия другим сотрудникам. Другие же ограничиваются только распределением задач. На самом деле вы должны отстаивать интересы заказчика внутри вашей команды, а значит ставить задачи и контролировать процесс их выполнения в полной мере.

Многие начинающие руководители недооценивают необходимость грамотной постановки задач, хотя это напрямую влияет на качество их выполнения. По этой причине в современных методологиях вышеупомянутой проблеме уделяется больше внимание. Мы будем рассматривать постановку задач в процессе разработки ПО.

Методики постановки задач:

— S.M.A.R.T. является аббревиатурой, где каждая буква означает критерий эффективности поставленных целей или задач.

— Specific — (конкретный) — нацельте на конкретную область для улучшения

— Measurable — (измеримый) — дайте количественную оценку или предложите показатель прогресса

— Assignable/Attainable — (назначаемый/достижимый) — укажите конкретного исполнителя

— Realistic — (реалистичный) — опишите, какие результаты могут быть реально достигнуты при наличии ресурсов

— Time related/Tangible — (связанный со временем/осязаемый) — укажите, когда может или должен быть достигнут результат

— User story (пользовательские истории). Если говорить про Agile разработку, то пользовательские истории рекомендованы как наиболее простой и понятный заказчику способ. Но вместе с простотой появляются проблемы с невыявленными требованиями. Предложено несколько формул пользовательских историй:

— Я как <Роль> могу <Функционал>, чтобы <Получить ценность>

— Для того чтобы мне <Получить ценность> как <Роль>, я могу <цель/возможность>

— Как <Кто> <Когда> <Где> я <Хочу>, потому что <Причина>

— К пользовательским историям и не только часто применяется I.N.V.E.S.T. метод

— Independent (независимость) — Старайтесь избегать создания задач, которые зависят друг от друга

— Negotiable (обсуждаемость) — задачи не являются формальным контрактным обязательством или требованиями

— Valuable — ценность для пользователя и покупателя

— Estimable (оцениваемость) — разработчики должны иметь возможность оценить размер задачи

— Small (компактность) — от размера задачи зависит очень многое, слишком большие и слишком маленькие задачи сложно оценивать

— Testable (тестируемость) — подтверждением того, что задача разработана успешно, служит удачное прохождение тестов

— DoD (Definition of Done) — критерий готовности, некий формальный набор работ/мероприятий, свидетельствующий о законченности задачи. В этот список могут попасть автотесты, документация и проведено ревью. Набор необходимых условий для решения задачи.

— Acceptance Criteria — критерии приемки,